Insecure Deserialization
This is quite a broad definition, but in simple terms, insecure deserialization is replacing data processed by an application with malicious code, allowing anything from DoS to RCE that the attacker can use to gain a foothold in a pentesting scenatio.
OWASP rank this vuln as 8 out of the top 10 for the following reasons
- Low exploitability - vuln is often a case-by-case basis and there's no reliable tool or framework for it. As a result attackers need a good understanding of the target's inner workings.
- The exploit is only as dangerous as the attacker's skill permits, more so, the value of the data exposed. For example, osmeone who can only cause a DOS will make the application unavailable. The business impact of this varys on infrastructure, some orgs recover just fine, some don't.
Any application that stores or fetches data where there's no validations or integrity checks in place for the data queried or retained can be susceptible to this to varying degrees.
- Ecommerce sites
- Forums
- APIs
- Application Runtimes (Tomcat, Jenkins, Jboss, etc)
Insecure Deserialization - Objects
A prominent element of object-oriented programming (OOP), objects are made up of two things:
- State
- Behaviour
Simply, objects allow you to create similar lines of code without having to do the leg-work of writing the same lines of code again.
For example, a lamp would be a good object. Lamps can have different types of bulbs, this would be their state, as well as being either on/off - their behaviour!
Insecure Deserialisation - Deserialisation
A Tourist approaches you in the street asking for directions. They're looking for a local landmark and got lost. Unfortunately, English isn't their strong point and nor do you speak their dialect either. What do you do? You draw a map of the route to the landmark because pictures cross language barriers, they were able to find the landmark. Nice! You've just serialised some information, where the tourist then deserialised it to find the landmark.
Say you have a password of "password123" from a program that needs to be stored in a database on another system. To travel across a network this string/output needs to be converted to binary. Of course, the password needs to be stored as "password123" and not its binary notation. Once this reaches the database, it is converted or deserialised back into "password123" so it can be stored.
The process is best explained through diagrams:
Simply put, insecure deserialisation occurs when data from an untrusted party gets executed because there's no filtering or input validation, the system assumes the data is trustworthy and will execute no holds barred.
Cookies
Yeah don't do this lol
Whilst plaintext credentials are vulns in of themselves, it's not insecure deserialization as we haven't sent any serialized data to be executed!
Cookies aren't permanent storage solutions like DBs, some cookies such as session IDs will clear when the browser is closed although they last considerably longer. This is determined by the "Expiry" timer when the cookie is created.
Cookies can be set in various website programming languages
Modified from 'user' to 'admin' on userType
